Description

Importing a certificate from a SerializedCert import can import the identifier for a private key, but doesn't actually import the key itself. This violates an assumption in the single-cert import path, and results in a massive surprise when the key is erased on Dispose/Finalize.

Customer Impact

If a customer has a certificate with a private key, exports it as SerializedCert, and then re-imports it later on the same system (or a system with a compatible persisted import) then the X509Certificate2 object will erase the persisted private key from disk when the object is freed.
We believe usage of SerializedCert is very low, but the impact is potentially very high.

Regression

Regression from .NET Framework

Testing

Added a new test to cover the scenario for both single-cert import (affected) and collection import (not affected).

Risk

Low. There are a large number of unit tests for other, existing, behavior; and this change makes the single-cert import look more like it did in .NET Framework (and does in collection import) with regard to registering for key cleanup.

original pr dotnet/runtime#33603
issue dotnet/runtime#33543

@bartonjs I assume the original customer is on 3.1 - this is sufficiently serious in your view that we should consider porting to 2.1 as well without any customer report there?

The bug is there, and it's really surprising and hard to figure out when it happens (largely because the X509Certificate2 constructor is so flexible). If servicing wants to assume that few new 2.1 workloads are being built and not take this change because of a lack of historical complaints, I can accept that.

@Anipik just wanted to make sure you saw this one, since it's been some time since we serviced 2.1.